home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9611 / 000137_owner-urn-ietf _Tue Nov 12 12:01:06 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  4KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA21389 for urn-ietf-out; Tue, 12 Nov 1996 12:01:06 -0500
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA21384 for <urn-ietf@services.bunyip.com>; Tue, 12 Nov 1996 12:01:03 -0500
  3. Received: from IG.CS.UTK.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA02342  (mail destined for urn-ietf@services.bunyip.com); Tue, 12 Nov 96 12:01:01 -0500
  5. Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK)
  6.           id LAA17005; Tue, 12 Nov 1996 11:57:44 -0500 (EST)
  7. Message-Id: <199611121657.LAA17005@ig.cs.utk.edu>
  8. X-Mailer: exmh version 1.6.7 5/3/96
  9. X-Uri: http://www.cs.utk.edu/~moore/
  10. From: Keith Moore <moore@cs.utk.edu>
  11. To: Fisher Mark <FisherM@is3.indy.tce.com>
  12. Cc: "Dirk.vanGulik" <Dirk.vanGulik@jrc.it>,
  13.         "girod@LCS.MIT.EDU" <girod@LCS.MIT.EDU>,
  14.         "Harald.T.Alvestrand@uninett.no" <Harald.T.Alvestrand@uninett.no>,
  15.         "mduerst@ifi.unizh.ch" <mduerst@ifi.unizh.ch>,
  16.         "moore@cs.utk.edu" <moore@cs.utk.edu>,
  17.         "tallen@fsc.fujitsu.com" <tallen@fsc.fujitsu.com>,
  18.         "urn-ietf@bunyip.com" <urn-ietf@bunyip.com>
  19. Subject: Re: [URN] I18N does not belong in URNs 
  20. In-Reply-To: Your message of "Tue, 12 Nov 1996 09:37:00 EST."
  21.              <32888C2E@MSMAIL.INDY.TCE.COM> 
  22. Mime-Version: 1.0
  23. Content-Type: text/plain; charset=us-ascii
  24. Date: Tue, 12 Nov 1996 11:57:43 -0500
  25. Sender: owner-urn-ietf@services.bunyip.com
  26. Precedence: bulk
  27. Reply-To: Keith Moore <moore@cs.utk.edu>
  28. Errors-To: owner-urn-ietf@bunyip.com
  29.  
  30. > >The reason for _not_ allowing any octet in the string after urn: is to
  31. > >avoid entering into the dark realm of having to retrive MIB like display
  32. > >strings whenever you encounter a URN you've not seen before; and which
  33. > >you would like to display to a human in such a way he/she can still
  34. > >transcribe it. Just showing a list of two digit hex numbers would not do.
  35. > 
  36. > Realistically, how often should we expect a resource that we _can_ read to 
  37. > be expressed by a URN that we can't read (i.e. the URN needs the %XX 
  38. > encoding convention)?  I would maintain that this would be the
  39. > unusual case. 
  40.  
  41. I disagree, for several reasons:
  42.  
  43. 1. many resources don't require a particular language.
  44.  
  45. 2. even if you can read the language, you might not be able to type in
  46. the characters on your keyboard.
  47.  
  48. 3. machines are getting better at automatic language translation.
  49. it's entirely possible, perhaps likely, that in a few years your web
  50. browser will have plugins that let it translate from other languages
  51. to the one you read best.  it might not be as good as being able to
  52. read the original language, but it will be good enough to understand
  53. most of what's being said.
  54.  
  55. URNs are defined to have global scope.  A name that is usable only by
  56. a Chinese speaker (or for that matter, an English speaker) isn't a
  57. URN.
  58.  
  59. The reason you assign a URN to something is to make it usable by a
  60. potentially global audience for a potentially long time.  (That
  61. doesn't mean that it's usable by anybody -- there can always be access
  62. controls-- but it does mean that who can use the resource isn't
  63. pre-determined when the name is assigned.)
  64.  
  65. If you don't want your resource to be globally usable, don't give it a
  66. URN.  Or conversely, if you want to prevent someone who doesn't speak
  67. your language from trying to read your resources, URNs aren't the
  68. right mechanism for doing this.
  69.  
  70. >  Otherwise, we might as well go with sequences of random digits.
  71.  
  72. Yes, that's much closer to what URNs are (IMHO) supposed to be.
  73. It also has the advantage of being much easier to implement.
  74.  
  75. Keith
  76.  
  77.